DevOps Overview BTech CSE Sem V · UPES Dehradun
Unit I · Lecture 2

Dev vs Ops Conflict
& the Agile Movement

Why developers and operations teams fought — and how Agile
changed the way we think about building software.

COURSE
DevOps Overview
UNIT
I of IV
LECTURE
2 of series
PREV. LECTURE
Waterfall Method

Dr. Mohsin Furkh Dar  ·  School of Computer Science, UPES Dehradun

Overview

What We Cover Today

🔥 Dev vs Ops Conflict
Why developers and IT operations teams had fundamentally different — and clashing — goals.
🧱 The Wall of Confusion
How the handoff between development and operations created a structural communication breakdown.
⚡ Waterfall's Role
How sequential development amplified Dev-Ops tensions and made collaboration harder.
📜 Agile Manifesto 2001
The four values and twelve principles that redefined software development practice.
🔄 Agile in Practice
How Agile teams work — sprints, iterations, feedback loops, and customer involvement.
🔗 Bridge to DevOps
Why Agile alone did not solve everything — and why DevOps emerged to close the gap.
Context — From Lecture 1

How Waterfall Set the Stage for Conflict

Waterfall's sequential, phase-gated model created organisational silos. Different teams owned different phases — and when the project moved to the next phase, the previous team's job was "done." This structure directly seeded the Dev vs Ops conflict.

Development Team's World

  • Requirements → Design → Code → hand off
  • Success = features delivered on schedule
  • Works in their own dev/test environment
  • Rarely sees how code behaves in production
  • Incentivised to move fast, add features

Operations Team's World

  • Receives finished software — must deploy and run it
  • Success = stable, available production systems
  • Manages servers, networks, databases, monitoring
  • Feels every bug and outage directly
  • Incentivised to change nothing, avoid risk
Waterfall's handoff model meant Dev and Ops rarely interacted — until something went wrong in production.
The Core Conflict

The "Wall of Confusion"

🧑‍💻 Development

  • "It works on my machine"
  • Pushes frequent changes
  • Wants rapid deployments
  • Optimises for speed & features
  • Often unaware of production constraints
  • Frustrated by deployment delays
  • Blames Ops for blocking releases
WALL
OF
CONF-
USION

🖥️ IT Operations

  • "Works in dev ≠ works in prod"
  • Resists frequent changes
  • Wants stability & predictability
  • Optimises for uptime & reliability
  • Unfamiliar with new code internals
  • Frustrated by poor deployment docs
  • Blames Dev for unstable releases
The "Wall of Confusion" — term popularised in the DevOps community to describe this structural handoff failure
Impact

Real Consequences of the Dev vs Ops Divide

Months
between releases in many orgs
72%
of outages caused by change
Blame
culture instead of shared ownership
💥
Slow releases
Deployments were manual, risky, and infrequent — often scheduled for late Friday nights to allow weekend recovery time.
💥
Environment drift
"Works on my machine" — dev, staging, and production environments diverged, causing unpredictable failures at release time.
💥
Blame culture
When production incidents happened, Dev and Ops pointed fingers at each other rather than collaborating on the root cause.
💥
Customer impact
End users experienced long wait times for new features, frequent downtime, and bugs that had been fixed in dev but not in production.
02

The Agile Movement

February 2001 — Snowbird, Utah
17 practitioners write a manifesto that changes software development forever

Origins

Why Agile Emerged — The Frustrations Behind It

By the late 1990s, software teams worldwide were frustrated with heavyweight, document-driven processes. Waterfall projects took years to deliver — by which time, customer needs had shifted and the delivered software was already obsolete.
  • 1990s: Multiple lightweight methods emerge independently — Scrum (1993), Extreme Programming / XP (1996), DSDM (1994), Crystal, Feature-Driven Development.
  • 1999: Kent Beck publishes Extreme Programming Explained — introduces test-driven development, continuous integration, pair programming.
  • 2000: Community momentum builds. Practitioners realise they share common values despite different methods.
  • Feb 2001: 17 software developers gather at Snowbird ski resort, Utah. Over two days, they produce the Agile Manifesto — four values, twelve principles.
  • Key insight: The problem was not just process — it was the wrong mindset about how software should be built. Agile is a philosophy before it is a methodology.
Agile Manifesto 2001

The Four Core Values

01
Individuals and interactions
over
processes and tools
02
Working software
over
comprehensive documentation
03
Customer collaboration
over
contract negotiation
04
Responding to change
over
following a plan
"That is, while there is value in the items on the right, we value the items on the left more." — Agile Manifesto
Agile Values — Unpacked

What Each Value Really Means

Individuals & Interactions

  • Face-to-face communication over ticket systems and long email chains
  • Self-organising teams over rigid role hierarchies
  • Trust developers to make decisions, not just follow instructions
  • Motivated individuals over process compliance

Working Software

  • Deliver something runnable every iteration — not just documents
  • "Done" means deployed and functional, not signed-off on paper
  • Documentation that serves the team — not documentation for its own sake
  • Primary measure of progress = working software, not completed phases

Customer Collaboration

  • Customer involved throughout — not only at start and end
  • Frequent feedback loops instead of big bang final demos
  • Shared ownership of outcomes between team and customer
  • Contracts define collaboration terms, not lock requirements in stone

Responding to Change

  • Changing requirements are welcomed, even late in development
  • Plans are a starting point, not a contract
  • Short iterations make course-correction cheap
  • The ability to adapt is a competitive advantage, not a failure
Agile Manifesto — Behind the Values

The 12 Principles at a Glance

Customer satisfaction first
Earliest and continuous delivery of valuable software is the top priority.
Welcome changing requirements
Even late changes — Agile harnesses change for the customer's competitive advantage.
Frequent delivery
Working software delivered often — weeks, not months. Shorter timescales preferred.
Daily collaboration
Business people and developers work together daily throughout the project.
Motivated individuals
Build projects around motivated people. Give them environment, trust, and support.
Face-to-face conversation
Most efficient method of conveying information within a development team.
Working software = progress
Primary measure of progress is working software, not completed documentation.
Sustainable pace
Sponsors, developers, and users maintain a constant, sustainable pace indefinitely.
Technical excellence
Continuous attention to good design and technical quality enhances agility.
Simplicity
Maximise the amount of work not done — do the simplest thing that works.
Self-organising teams
Best architectures, requirements, and designs emerge from self-organising teams.
Regular reflection
Team reflects on how to become more effective at regular intervals and adjusts.
Agile in Practice

Iterative Development — How Agile Teams Work

Instead of one massive delivery after years of work, Agile teams deliver in short cycles called sprints or iterations (typically 1–4 weeks). Each iteration produces a potentially shippable increment of working software.
①
Plan Sprint
Team selects a small set of features from the backlog. Estimates effort, defines acceptance criteria. Time-boxed planning — typically half a day.
②
Build & Test
Developers design, code, and test within the sprint. Daily standup (15 min) keeps the team aligned. Testing happens continuously — not as a separate phase.
③
Sprint Review
Working software demonstrated to the customer and stakeholders. Feedback collected immediately — not after months of work.
④
Retrospective
Team reflects: what went well, what to improve, what to try differently. Continuous process improvement baked into every cycle.
↺
Repeat
Next sprint begins immediately. Feedback from the review updates the backlog — the plan adapts to new information every single cycle.
Comparison

Agile vs Waterfall — Side by Side

Dimension Waterfall Agile
Requirements Fixed upfront, documented fully Evolve continuously with customer input
Delivery Single release at project end Working software every 1–4 weeks
Customer role Defines requirements, then waits Actively involved throughout
Change response Expensive — change control process required Welcome — backlog updated each sprint
Testing After all code written Continuous — within every sprint
Team structure Separate specialised teams by phase Cross-functional team owns full delivery
Risk profile Back-loaded — failure visible only at end Front-loaded — risks surfaced early
Documentation Extensive, formal, phase-gated Just enough — serves the team's needs
The Gap Agile Left

Agile Solved Dev — But Not Dev vs Ops

Agile transformed how development teams worked — but it largely stopped at the deployment boundary. Operations teams were not part of the Agile conversation. The Wall of Confusion survived.

✅ What Agile Fixed

  • Dev teams deliver working software frequently
  • Customer feedback incorporated continuously
  • Requirements can change without crisis
  • Team collaboration and morale improved
  • Quality improved through continuous testing
  • Reduced time from idea to code completion

❌ What Agile Did Not Fix

  • Dev still throws releases "over the wall" to Ops
  • Operations still not involved until deployment
  • Infrastructure still manual, slow, and fragile
  • Deployment frequency still limited by Ops capacity
  • Monitoring, feedback from production still slow
  • "We're Agile in dev but Waterfall in ops"
This gap — fast Agile development, slow manual operations — is precisely why DevOps was born. DevOps extends Agile values across the entire delivery pipeline, including deployment, infrastructure, and monitoring.
Lecture Wrap-Up

Key Takeaways & What's Next

💡
Root of conflict
Dev and Ops have structurally opposite incentives — Dev wants change, Ops wants stability. Waterfall formalised this separation into organisational silos.
💡
Wall of Confusion
The one-way handoff from Dev to Ops created blame culture, environment drift, infrequent releases, and slow recovery from incidents.
💡
Agile Manifesto
Four values and twelve principles reoriented software development around people, working software, collaboration, and adaptability — not processes and documents.
💡
Agile's contribution
Short iterations, continuous testing, and frequent customer feedback reduced risk and improved quality inside the development cycle significantly.
💡
Agile's limit
Agile did not bridge the Dev-Ops divide. Deployment and operations remained slow and manual — setting the stage for the DevOps movement.
➡️
Next lecture
Agile vs Waterfall in depth, iterative Agile software development, and a deep dive into each of the four Agile Manifesto values.
DevOps Overview · Unit I · Lecture 2  ·  Dr. Mohsin Furkh Dar  ·  UPES Dehradun · Summer 2026
← → or swipe